image's high-level API doesn't accept quality parameters and I want to follow the design. How about providing a separate decoding function with a complex configuration? Such a function may accept an extendable option type like WebPDecoderOptions from libwebp (C). Existing APIs like JpegEncoder may be of some help.

So I will create a WebpEncoder struct which you can create with a custom quality_factor or not, and it will wrap the current webp_write methods instead of having them be freestanding functions. If it was "just" a custom function, I would have to duplicate every single function to have one variant which includes the parameter and one variant which doesn't.

I also added that Compression API now so I can use this crate for lossless compression as well.

Yes, it could; here's a proof of concept implementation.
Note that it only encodes for the color types libwebp directly supports, inspired by how image does it: https://docs.rs/image/0.23.14/src/image/codecs/jpeg/encoder.rs.html#439
I could add something like this to the match color_type with relative ease (16-bit color types are more complicated):

ColorType::L8 => {
    let img = DynamicImage::ImageLuma8(
        ImageBuffer::from_raw(width, height, buf.to_vec()).unwrap(),
    );
    self.encode_rgb(&img.to_rgb8())
}
ColorType::La8 => {
    let img = DynamicImage::ImageLumaA8(
        ImageBuffer::from_raw(width, height, buf.to_vec()).unwrap(),
    );
    self.encode_rgba(&img.to_rgba8())
}

However this might be a hidden cost as we need an allocation (.to_vec()) to create that DynamicImage, so I've left that out for now and opted to stay more close to how image does it.

I would like to document this behavior (and most of the library) in another commit if that's ok, but I can also do a new PR for that if you prefer.

As you said, following JpegEncoder's behavior seems better.

I would like to document this behavior (and most of the library) in another commit if that's ok

The document would be helpful. Could you go ahead and provide one?